home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9701 / 000061_owner-urn-ietf _Fri Jan 31 17:02:36 1997.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA14297 for urn-ietf-out; Fri, 31 Jan 1997 17:02:36 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA14291 for <urn-ietf@services.bunyip.com>; Fri, 31 Jan 1997 17:02:34 -0500
  3. Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA01831  (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 17:02:00 -0500
  5. Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) 
  6.           id <17158-0@josef.ifi.unizh.ch>; Fri, 31 Jan 1997 22:57:55 +0100
  7. Date: Fri, 31 Jan 1997 22:57:54 +0100 (MET)
  8. From: "Martin J. Duerst" <mduerst@ifi.unizh.ch>
  9. To: "Ron Daniel Jr." <rdaniel@lanl.gov>
  10. Cc: Daniel LaLiberte <liberte@ncsa.uiuc.edu>,
  11.         URL mailing list <ietf-url@imc.org>, urn-ietf <urn-ietf@bunyip.com>
  12. Subject: Re: [URN] Re: Relative URLs and URNs
  13. In-Reply-To: <3.0.32.19970131141946.009654f0@acl.lanl.gov>
  14. Message-Id: <Pine.SUN.3.95q.970131225421.246h-100000@enoshima>
  15. Mime-Version: 1.0
  16. Content-Type: TEXT/PLAIN; charset=US-ASCII
  17. Sender: owner-urn-ietf@services.bunyip.com
  18. Precedence: bulk
  19. Reply-To: "Martin J. Duerst" <mduerst@ifi.unizh.ch>
  20. Errors-To: owner-urn-ietf@bunyip.com
  21.  
  22. On Fri, 31 Jan 1997, Ron Daniel Jr. wrote:
  23.  
  24. > Thus spoke Daniel LaLiberte:
  25. > >Ron Daniel, Jr. writes:
  26. > > > The point I was trying to make is that the presence of the relative
  27. > > > URLs is not helping us as we make the transition to URNs.
  28. > >
  29. > >Relative URLs (which are relative URIs intended to be interpreted
  30. > >relative to an absolute URL) would not interfere with a transition
  31. > >to URNs if you keep the same absolute URL base.
  32. > 
  33. > Not always true. If our resolver offers the N2R service, its nice to
  34. > use it because bookmarks will be to the URN, not to a URL. Similarly,
  35. > the Location: text field in netscape will display the URN. However,
  36. > that means that relative URIs will be relative to the URN, not the
  37. > URL of the instance we fetch. Since the hierarchies are not the same,
  38. > it breaks.
  39.  
  40. The problem that the thing you want to have in the bookmark and the
  41. thing you want to use for relative URL resolving are not the same
  42. was discussed earlier in quite some detail. It might be time to
  43. split these into two. But then again, I'm not at all sure whether
  44. this will lead to a consistent model for relative URNs, or whether
  45. this will contribute to the need for relative URNs.
  46.  
  47.  
  48. Regards,    Martin.
  49.